با تحلیل و بهینه‌سازی مسیر رندرینگ بحرانی، بر عملکرد وب مسلط شوید. راهنمای جامع برای توسعه‌دهندگان درباره تأثیر جاوااسکریپت بر رندرینگ و نحوه رفع مشکلات آن.
بهینه‌سازی عملکرد جاوااسکریپت: کاوشی عمیق در مسیر رندرینگ بحرانی
در دنیای توسعه وب، سرعت تنها یک ویژگی نیست؛ بلکه ستون فقرات یک تجربه کاربری خوب است. یک وب‌سایت کند می‌تواند منجر به نرخ پرش بالاتر، تبدیل کمتر و مخاطبان ناامید شود. در حالی که عوامل زیادی به عملکرد وب کمک می‌کنند، یکی از اساسی‌ترین و اغلب سوءتفاهم‌شده‌ترین مفاهیم، مسیر رندرینگ بحرانی (CRP) است. درک نحوه رندر محتوا توسط مرورگرها و، مهم‌تر از آن، نحوه تعامل جاوااسکریپت با این فرآیند، برای هر توسعه‌دهنده‌ای که به عملکرد جدی است، بسیار حائز اهمیت است.
این راهنمای جامع شما را در یک کاوش عمیق در مسیر رندرینگ بحرانی، با تمرکز ویژه بر نقش جاوااسکریپت، همراهی می‌کند. ما نحوه تحلیل آن، شناسایی گلوگاه‌ها و اعمال تکنیک‌های بهینه‌سازی قدرتمند را بررسی خواهیم کرد که برنامه‌های وب شما را برای کاربران جهانی سریع‌تر و پاسخگوتر می‌کند.
مسیر رندرینگ بحرانی چیست؟
مسیر رندرینگ بحرانی توالی مراحلی است که مرورگر باید برای تبدیل HTML، CSS و جاوااسکریپت به پیکسل‌های قابل مشاهده روی صفحه طی کند. هدف اصلی بهینه‌سازی CRP، رندر کردن محتوای اولیه و "بالای خط تاخوردگی" به کاربر در سریع‌ترین زمان ممکن است. هرچه این اتفاق سریع‌تر بیفتد، کاربر صفحه را سریع‌تر بارگذاری شده می‌بیند.
این مسیر شامل چندین مرحله کلیدی است:
- ساخت DOM: این فرآیند زمانی آغاز می‌شود که مرورگر اولین بایت‌های سند HTML را از سرور دریافت می‌کند. شروع به تجزیه و تحلیل نشانه‌گذاری HTML، کاراکتر به کاراکتر می‌کند و مدل شیء سند (DOM) را می‌سازد. DOM یک ساختار درختی است که تمام گره‌ها (عناصر، ویژگی‌ها، متن) را در سند HTML نمایش می‌دهد.
- ساخت CSSOM: همانطور که مرورگر DOM را می‌سازد، اگر با یک شیوه نامه CSS (چه در تگ
<link>یا یک بلوک<style>درون‌خطی) مواجه شود، شروع به ساخت مدل شیء CSS (CSSOM) می‌کند. مشابه DOM، CSSOM یک ساختار درختی است که شامل تمام سبک‌ها و روابط آنها برای صفحه است. برخلاف HTML، CSS به طور پیش‌فرض مسدودکننده رندر است. مرورگر نمی‌تواند هیچ بخشی از صفحه را رندر کند تا زمانی که تمام CSS را دانلود و تجزیه کرده باشد، زیرا سبک‌های بعدی می‌توانند سبک‌های قبلی را نادیده بگیرند. - ساخت درخت رندر: هنگامی که هر دو DOM و CSSOM آماده شدند، مرورگر آنها را ترکیب می‌کند تا درخت رندر را ایجاد کند. این درخت فقط شامل گره‌های مورد نیاز برای رندر صفحه است. به عنوان مثال، عناصر با
display: none;و تگ<head>در درخت رندر گنجانده نمی‌شوند زیرا به صورت بصری رندر نمی‌شوند. درخت رندر می‌داند چه چیزی را نمایش دهد، اما نه کجا یا با چه ابعادی. - چیدمان (یا Reflow): با ساخته شدن درخت رندر، مرورگر به مرحله چیدمان می‌پردازد. در این مرحله، اندازه و موقعیت دقیق هر گره در درخت رندر را نسبت به نمای مشاهده محاسبه می‌کند. خروجی این مرحله یک "مدل جعبه‌ای" است که هندسه دقیق هر عنصر در صفحه را ثبت می‌کند.
- نقاشی: در نهایت، مرورگر اطلاعات چیدمان را گرفته و پیکسل‌ها را برای هر گره روی صفحه "نقاشی" می‌کند. این شامل کشیدن متن، رنگ‌ها، تصاویر، حاشیه‌ها و سایه‌ها است — اساساً هر بخش بصری از صفحه را رسترایز می‌کند. این فرآیند می‌تواند در لایه‌های متعدد برای بهبود کارایی اتفاق بیفتد.
- ترکیب: اگر محتوای صفحه روی چندین لایه نقاشی شده باشد، مرورگر باید این لایه‌ها را به ترتیب صحیح ترکیب کند تا تصویر نهایی روی صفحه نمایش داده شود. این مرحله به ویژه برای انیمیشن‌ها و اسکرول مهم است، زیرا ترکیب معمولاً از اجرای مجدد مراحل چیدمان و نقاشی از نظر محاسباتی کم‌هزینه‌تر است.
نقش مختل‌کننده جاوااسکریپت در مسیر رندرینگ بحرانی
پس جاوااسکریپت در این تصویر کجا قرار می‌گیرد؟ جاوااسکریپت یک زبان قدرتمند است که می‌تواند هم DOM و هم CSSOM را تغییر دهد. با این حال، این قدرت هزینه‌ای دارد. جاوااسکریپت می‌تواند، و اغلب اوقات، مسیر رندرینگ بحرانی را مسدود کند که منجر به تأخیرهای قابل توجهی در رندرینگ می‌شود.
جاوااسکریپت مسدودکننده تجزیه‌گر
به طور پیش‌فرض، جاوااسکریپت مسدودکننده تجزیه‌گر است. هنگامی که تجزیه‌گر HTML مرورگر با تگ <script> مواجه می‌شود، باید فرآیند ساخت DOM را متوقف کند. سپس به دانلود (در صورت خارجی بودن)، تجزیه و اجرای فایل جاوااسکریپت می‌پردازد. این فرآیند مسدودکننده است زیرا اسکریپت ممکن است کاری مانند document.write() انجام دهد که می‌تواند کل ساختار DOM را تغییر دهد. مرورگر چاره‌ای جز صبر کردن برای اتمام اسکریپت ندارد تا بتواند با خیال راحت تجزیه HTML را از سر بگیرد.
اگر این اسکریپت در <head> سند شما قرار داشته باشد، ساخت DOM را از همان ابتدا مسدود می‌کند. این بدان معناست که مرورگر محتوایی برای رندر کردن ندارد و کاربر تا زمانی که اسکریپت به طور کامل پردازش شود، به یک صفحه سفید خالی خیره می‌ماند. این یکی از دلایل اصلی عملکرد ضعیف ادراک‌شده است.
دستکاری DOM و CSSOM
جاوااسکریپت همچنین می‌تواند CSSOM را پرس و جو کرده و تغییر دهد. به عنوان مثال، اگر اسکریپت شما یک سبک محاسبه شده مانند element.style.width را درخواست کند، مرورگر باید ابتدا مطمئن شود که تمام CSS دانلود و تجزیه شده است تا پاسخ صحیح را ارائه دهد. این یک وابستگی بین جاوااسکریپت و CSS شما ایجاد می‌کند، جایی که ممکن است اجرای اسکریپت در انتظار آماده شدن CSSOM مسدود شود.
علاوه بر این، اگر جاوااسکریپت DOM (مثلاً اضافه یا حذف یک عنصر) یا CSSOM (مثلاً تغییر یک کلاس) را تغییر دهد، می‌تواند باعث یک آبشار از کارهای مرورگر شود. یک تغییر ممکن است مرورگر را مجبور به محاسبه مجدد چیدمان (یک reflow) و سپس نقاشی مجدد قسمت‌های متاثر شده از صفحه، یا حتی کل صفحه کند. دستکاری‌های مکرر یا با زمان‌بندی نامناسب می‌تواند منجر به یک رابط کاربری کند و غیرپاسخگو شود.
نحوه تحلیل مسیر رندرینگ بحرانی
قبل از اینکه بتوانید بهینه‌سازی کنید، ابتدا باید اندازه‌گیری کنید. ابزارهای توسعه‌دهنده مرورگر بهترین دوست شما برای تحلیل CRP هستند. بیایید روی Chrome DevTools تمرکز کنیم، که مجموعه‌ای قدرتمند از ابزارها را برای این منظور ارائه می‌دهد.
استفاده از تب Performance
تب Performance یک تایم‌لاین دقیق از هر کاری که مرورگر برای رندر صفحه شما انجام می‌دهد، ارائه می‌دهد.
- Chrome DevTools را باز کنید (Ctrl+Shift+I یا Cmd+Option+I).
- به تب Performance بروید.
- اطمینان حاصل کنید که کادر انتخاب "Web Vitals" علامت خورده است تا معیارهای کلیدی روی تایم‌لاین نمایش داده شوند.
- دکمه بارگذاری مجدد (یا Ctrl+Shift+E / Cmd+Shift+E را فشار دهید) را کلیک کنید تا پروفایل‌سازی بارگذاری صفحه آغاز شود.
پس از بارگذاری صفحه، یک نمودار شعله‌ای به شما نمایش داده می‌شود. در بخش Main thread به دنبال این موارد باشید:
- Long Tasks: هر کاری که بیش از 50 میلی‌ثانیه طول بکشد با یک مثلث قرمز مشخص می‌شود. اینها نامزدهای اصلی برای بهینه‌سازی هستند زیرا رشته اصلی را مسدود می‌کنند و می‌توانند UI را غیرپاسخگو کنند.
- Parse HTML (آبی): این به شما نشان می‌دهد که مرورگر در حال تجزیه HTML شماست. اگر شکاف‌ها یا وقفه‌های بزرگی را مشاهده کردید، احتمالاً به دلیل یک اسکریپت مسدودکننده است.
- Evaluate Script (زرد): اینجاست که جاوااسکریپت در حال اجرا است. به دنبال بلوک‌های زرد طولانی، به خصوص در اوایل بارگذاری صفحه باشید. اینها اسکریپت‌های مسدودکننده شما هستند.
- Recalculate Style (بنفش): این نشان‌دهنده ساخت CSSOM و محاسبات سبک است.
- Layout (بنفش): این بلوک‌ها نشان‌دهنده مرحله چیدمان یا reflow هستند. اگر تعداد زیادی از اینها را مشاهده کردید، ممکن است جاوااسکریپت شما با خواندن و نوشتن مکرر ویژگی‌های هندسی، باعث "layout thrashing" شود.
- Paint (سبز): این فرآیند نقاشی است.
استفاده از تب Network
نمودار آبشار تب Network برای درک ترتیب و مدت زمان دانلود منابع بسیار ارزشمند است.
- DevTools را باز کرده و به تب Network بروید.
- صفحه را بارگذاری مجدد کنید.
- نمای آبشار به شما نشان می‌دهد که هر منبع (HTML، CSS، JS، تصاویر) چه زمانی درخواست و دانلود شده است.
به درخواست‌های بالای آبشار توجه ویژه‌ای داشته باشید. می‌توانید به راحتی فایل‌های CSS و جاوااسکریپت را که قبل از شروع رندر صفحه دانلود می‌شوند، پیدا کنید. اینها منابع مسدودکننده رندر شما هستند.
استفاده از Lighthouse
Lighthouse یک ابزار حسابرسی خودکار است که در Chrome DevTools (زیر تب Lighthouse) تعبیه شده است. این ابزار یک امتیاز عملکرد بالا و توصیه‌های عملی ارائه می‌دهد.
یک حسابرسی کلیدی برای CRP، "Eliminate render-blocking resources" است. این گزارش به صراحت فایل‌های CSS و جاوااسکریپت را که First Contentful Paint (FCP) را به تأخیر می‌اندازند، لیست می‌کند و لیستی واضح از اهداف برای بهینه‌سازی به شما می‌دهد.
استراتژی‌های بهینه‌سازی اصلی برای جاوااسکریپت
حالا که می‌دانیم چگونه مشکلات را شناسایی کنیم، بیایید راه‌حل‌ها را بررسی کنیم. هدف، به حداقل رساندن میزان جاوااسکریپتی است که رندر اولیه را مسدود می‌کند.
1. قدرت `async` و `defer`
ساده‌ترین و مؤثرترین راه برای جلوگیری از مسدود کردن تجزیه‌گر HTML توسط جاوااسکریپت، استفاده از ویژگی‌های `async` و `defer` در تگ‌های <script> شماست.
<script>استاندارد:<script src="script.js"></script>
همانطور که بحث کردیم، این مسدودکننده تجزیه‌گر است. تجزیه HTML متوقف می‌شود، اسکریپت دانلود و اجرا می‌شود، و سپس تجزیه از سر گرفته می‌شود.<script async>:<script src="script.js" async></script>
اسکریپت به صورت ناهمزمان، موازی با تجزیه HTML دانلود می‌شود. به محض اتمام دانلود اسکریپت، تجزیه HTML متوقف شده و اسکریپت اجرا می‌شود. ترتیب اجرا تضمین شده نیست؛ اسکریپت‌ها به محض در دسترس قرار گرفتن اجرا می‌شوند. این برای اسکریپت‌های مستقل و شخص ثالثی که به DOM یا سایر اسکریپت‌ها وابسته نیستند، مانند اسکریپت‌های تحلیل‌گر یا تبلیغاتی، بهترین گزینه است.<script defer>:<script src="script.js" defer></script>
اسکریپت به صورت ناهمزمان، موازی با تجزیه HTML دانلود می‌شود. با این حال، اسکریپت تنها پس از اینکه سند HTML به طور کامل تجزیه شد (درست قبل از رویداد `DOMContentLoaded`) اجرا می‌شود. اسکریپت‌های با `defer` نیز تضمین شده‌اند که به ترتیبی که در سند ظاهر می‌شوند، اجرا شوند. این روش ارجح برای اکثر اسکریپت‌هایی است که نیاز به تعامل با DOM دارند و برای نقاشی اولیه حیاتی نیستند.
قاعده کلی: برای اسکریپت‌های اصلی برنامه خود از `defer` استفاده کنید. برای اسکریپت‌های مستقل شخص ثالث از `async` استفاده کنید. از استفاده از اسکریپت‌های مسدودکننده در <head> خودداری کنید مگر اینکه برای رندر اولیه کاملاً ضروری باشند.
2. تقسیم کد (Code Splitting)
برنامه‌های وب مدرن اغلب در یک فایل جاوااسکریپت واحد و بزرگ بسته‌بندی می‌شوند. در حالی که این تعداد درخواست‌های HTTP را کاهش می‌دهد، کاربر را مجبور می‌کند که مقدار زیادی کد را دانلود کند که ممکن است برای مشاهده اولیه صفحه مورد نیاز نباشد.
تقسیم کد (Code Splitting) فرآیند شکستن آن بسته بزرگ به قطعات کوچک‌تر است که می‌توانند بر اساس تقاضا بارگذاری شوند. به عنوان مثال:
- قطعه اولیه: فقط شامل جاوااسکریپت ضروری است که برای رندر بخش قابل مشاهده صفحه فعلی لازم است.
- قطعات بر اساس تقاضا: شامل کد برای مسیرهای دیگر، مدال‌ها یا ویژگی‌های زیر خط تاخوردگی هستند. اینها فقط زمانی بارگذاری می‌شوند که کاربر به آن مسیر هدایت شود یا با آن ویژگی تعامل کند.
باندل‌سازهای مدرن مانند Webpack، Rollup و Parcel از تقسیم کد با استفاده از سینتکس داینامیک `import()` پشتیبانی داخلی دارند. فریم‌ورک‌هایی مانند React (با `React.lazy`) و Vue نیز راه‌های آسانی برای تقسیم کد در سطح کامپوننت ارائه می‌دهند.
3. Tree Shaking و حذف کد مرده (Dead Code Elimination)
حتی با تقسیم کد، بسته اولیه شما ممکن است شامل کدی باشد که در واقع استفاده نمی‌شود. این امر زمانی که شما کتابخانه‌ها را وارد می‌کنید اما فقط بخش کوچکی از آنها را استفاده می‌کنید، رایج است.
Tree Shaking فرآیندی است که توسط باندل‌سازهای مدرن برای حذف کد استفاده نشده از بسته نهایی شما استفاده می‌شود. این فرآیند به صورت ایستا عبارت‌های `import` و `export` شما را تحلیل می‌کند و تعیین می‌کند کدام کد غیرقابل دسترس است. با اطمینان از اینکه فقط کدی را ارسال می‌کنید که کاربران شما به آن نیاز دارند، می‌توانید اندازه‌های بسته را به طور قابل توجهی کاهش دهید که منجر به دانلود سریع‌تر و زمان‌های تجزیه کوتاه‌تر می‌شود.
4. فشرده‌سازی و Minification
اینها گام‌های اساسی برای هر وب‌سایت تولیدی هستند.
- Minification: این یک فرآیند خودکار است که کاراکترهای غیرضروری از کد شما — مانند فضای سفید، نظرات و خطوط جدید — را حذف می‌کند و نام متغیرها را کوتاه می‌کند، بدون اینکه عملکرد آن را تغییر دهد. این باعث کاهش اندازه فایل می‌شود. ابزارهایی مانند Terser (برای جاوااسکریپت) و cssnano (برای CSS) معمولاً استفاده می‌شوند.
- Compression: پس از minification، سرور شما باید فایل‌ها را قبل از ارسال به مرورگر فشرده کند. الگوریتم‌هایی مانند Gzip و، به طور مؤثرتر، Brotli می‌توانند اندازه‌های فایل را تا 70-80% کاهش دهند. سپس مرورگر آنها را پس از دریافت از حالت فشرده خارج می‌کند. این یک پیکربندی سرور است، اما برای کاهش زمان انتقال شبکه حیاتی است.
5. Inline کردن جاوااسکریپت بحرانی (با احتیاط استفاده کنید)
برای قطعات بسیار کوچک جاوااسکریپت که برای نقاشی اولیه کاملاً ضروری هستند (مثلاً تنظیم یک تم یا یک polyfill حیاتی)، می‌توانید آنها را مستقیماً در HTML خود در یک تگ <script> در <head> قرار دهید. این یک درخواست شبکه را ذخیره می‌کند، که می‌تواند در اتصالات موبایل با تأخیر بالا مفید باشد. با این حال، این باید به ندرت استفاده شود. کد inline شده اندازه سند HTML شما را افزایش می‌دهد و نمی‌تواند به طور جداگانه توسط مرورگر کش شود. این یک مصالحه است که باید با دقت در نظر گرفته شود.
تکنیک‌های پیشرفته و رویکردهای مدرن
رندرینگ سمت سرور (SSR) و تولید سایت ایستا (SSG)
فریم‌ورک‌هایی مانند Next.js (برای React)، Nuxt.js (برای Vue) و SvelteKit، SSR و SSG را محبوب کرده‌اند. این تکنیک‌ها کار رندر اولیه را از مرورگر مشتری به سرور منتقل می‌کنند.
- SSR: سرور HTML کامل را برای یک صفحه درخواستی رندر می‌کند و آن را به مرورگر می‌فرستد. مرورگر می‌تواند این HTML را بلافاصله نمایش دهد که منجر به First Contentful Paint بسیار سریع می‌شود. سپس جاوااسکریپت بارگذاری شده و صفحه را "هیدراته" می‌کند و آن را تعاملی می‌سازد.
- SSG: HTML برای هر صفحه در زمان ساخت تولید می‌شود. هنگامی که کاربر یک صفحه را درخواست می‌کند، یک فایل HTML ایستا فوراً از CDN ارائه می‌شود. این سریع‌ترین رویکرد برای سایت‌های پرمحتوا است.
هر دو SSR و SSG به طور چشمگیری عملکرد CRP را با ارائه یک نقاشی اولیه معنی‌دار قبل از اینکه بیشتر جاوااسکریپت سمت مشتری حتی شروع به اجرا کند، بهبود می‌بخشند.
Web Workers
اگر برنامه شما نیاز به انجام محاسبات سنگین و طولانی‌مدت (مانند تجزیه و تحلیل داده‌های پیچیده، پردازش تصویر یا رمزنگاری) دارد، انجام این کار در رشته اصلی، رندر را مسدود کرده و صفحه شما را منجمد نشان می‌دهد. Web Workers با اجازه دادن به شما برای اجرای این اسکریپت‌ها در یک رشته پس‌زمینه، کاملاً جدا از رشته اصلی UI، راه‌حلی ارائه می‌دهند. این کار برنامه شما را پاسخگو نگه می‌دارد در حالی که کارهای سنگین در پشت صحنه انجام می‌شوند.
یک گردش کار عملی برای بهینه‌سازی CRP
بیایید همه اینها را در یک گردش کار عملی که می‌توانید در پروژه‌های خود اعمال کنید، ترکیب کنیم.
- حسابرسی: با یک پایه شروع کنید. یک گزارش Lighthouse و یک پروفایل عملکرد را در ساختار تولیدی خود اجرا کنید تا وضعیت فعلی خود را درک کنید. FCP، LCP، TTI خود را یادداشت کنید و هر کار طولانی یا منابع مسدودکننده رندر را شناسایی کنید.
- شناسایی: به تب‌های Network و Performance DevTools بپردازید. دقیقاً مشخص کنید کدام اسکریپت‌ها و شیوه نامه‌ها رندر اولیه را مسدود می‌کنند. برای هر منبع از خود بپرسید: "آیا این برای کاربر کاملاً ضروری است که محتوای اولیه را ببیند؟"
- اولویت‌بندی: تلاش‌های خود را روی کدی متمرکز کنید که بر محتوای بالای خط تاخوردگی تأثیر می‌گذارد. هدف این است که این محتوا را در سریع‌ترین زمان ممکن به کاربر برسانیم. هر چیز دیگری می‌تواند بعداً بارگذاری شود.
- بهینه‌سازی:
- ویژگی
deferرا برای تمام اسکریپت‌های غیرضروری اعمال کنید. - برای اسکریپت‌های مستقل شخص ثالث از
asyncاستفاده کنید. - تقسیم کد را برای مسیرها و کامپوننت‌های بزرگ خود پیاده‌سازی کنید.
- اطمینان حاصل کنید که فرآیند ساخت شما شامل minification و tree shaking است.
- با تیم زیرساخت خود همکاری کنید تا فشرده‌سازی Brotli یا Gzip را در سرور خود فعال کنید.
- برای CSS، در نظر بگیرید که CSS حیاتی مورد نیاز برای نمای اولیه را inline کنید و بقیه را به صورت lazy-load بارگذاری کنید.
- ویژگی
- اندازه‌گیری: پس از اعمال تغییرات، حسابرسی را دوباره اجرا کنید. امتیازات و زمان‌بندی‌های جدید خود را با پایه مقایسه کنید. آیا FCP شما بهبود یافته است؟ آیا منابع مسدودکننده رندر کمتری وجود دارد؟
- تکرار: عملکرد وب یک راه‌حل یک‌بار مصرف نیست؛ این یک فرآیند مداوم است. با رشد برنامه شما، گلوگاه‌های عملکردی جدید می‌توانند ظاهر شوند. حسابرسی عملکرد را به بخشی منظم از چرخه توسعه و استقرار خود تبدیل کنید.
نتیجه‌گیری: تسلط بر مسیر عملکرد
مسیر رندرینگ بحرانی، طرح اولیه مرورگر برای زنده کردن برنامه شماست. به عنوان توسعه‌دهندگان، درک و کنترل ما بر این مسیر، به ویژه در مورد جاوااسکریپت، یکی از قدرتمندترین اهرم‌هایی است که برای بهبود تجربه کاربری در اختیار داریم. با حرکت از ذهنیت صرفاً نوشتن کدی که کار می‌کند به نوشتن کدی که عملکرد خوبی دارد، می‌توانیم برنامه‌هایی بسازیم که نه تنها کاربردی، بلکه سریع، قابل دسترس و لذت‌بخش برای کاربران در سراسر جهان باشند.
این سفر با تحلیل آغاز می‌شود. ابزارهای توسعه‌دهنده خود را باز کنید، برنامه خود را پروفایل‌سازی کنید و شروع به زیر سؤال بردن هر منبعی کنید که بین کاربر شما و یک صفحه کاملاً رندر شده قرار دارد. با اعمال استراتژی‌های تأخیر انداختن اسکریپت‌ها، تقسیم کد و به حداقل رساندن محموله خود، می‌توانید مسیر را برای مرورگر باز کنید تا کاری را که بهتر از هر چیز دیگری انجام می‌دهد: رندر کردن محتوا با سرعت رعد و برق.